1. Field of the Invention
The present invention relates generally to the field of IP communication, and more particularly to a method for providing Internet Protocol (IP) telephony with quality of service (QoS) using end-to-end Resource Reservation Protocol (RSVP) signaling.
2. Discussion of the Related Art
The Internet community is working toward one day having all forms of inter-personal communication carried over the Internet. Video broadcasts, radio transmissions, computer data and telephone systems will merge into one medium and be transported anywhere in the world without any loss of perceived quality.
In order to be commercially practicable however, IP communications such as IP telephony and other IP communication services will require a quality of service (QoS) equal to or better than that currently available on digital circuit switched networks. This requires end-to-end QoS in corporate IP networks and across the IP backbones that carry traffic between the end networks. While QoS is available, it requires the usage of network resources and therefore, service providers will only ensure QoS if authorization and payments are supported across the domains where the communications are taking place.
Several protocols and services have been developed to handle the various aspects of IP communications. For instance, Session Initiation Protocol (SIP) was developed for call setup; Open Settlement Protocol (OSP) was developed for authorization and usage reporting and is used between policy servers and a clearing house for pricing, usage exchange and settlements for services; Common Outsourcing Policy Service (COPS) was developed for policy deployment in network elements and is used between the policy server and other network elements to communicate policy applicable for microflows that have QoS support; Resource Reservation Protocol (RSVP) was developed for setting up QoS in end networks and refers to a signaling protocol to request QoS from the network. RSVP is an end-to-end signaling protocol and can be used between corresponding telephony clients in the respective domains; Subnet Bandwidth Manager (SBM) was developed for setting up RSVP initiated QoS in 802.x style LANs; and Differentiated Services (DiffServ) was developed for setting up QoS traffic classes in IP backbones.
In order to complete a phone call on the Internet, at least three things should occur. First, the called party has to be alerted. Second, the connection between the callers must be established, and finally, resources to connect to callers may have to be set aside exclusively for the conversation. These steps do not have to occur in this order however. To this end, SIP is responsible for establishing the session while RSVP is responsible for reserving the resources necessary for a call.
Providing IP communications with QoS across the Internet requires a common way of usage for call setup, authorization, and QoS. Though the individual protocols above have been developed in detail, there is currently no reported method on how to use the individual protocols together in a consistent way across the Internet. In addition, there are no reported methods for dynamically establishing QoS policy for SIP-based voice and video calls on the Internet.
It is therefore an object of the present invention to provide a method for implementing IP telephony with QoS using end-to-end RSVP signaling that is capable of providing an acceptable QoS during a IP communications across the Internet.
It is another object of the invention to provide a method for dynamically establishing QoS policy for SIP-based voice and video calls on the Internet.
It is an additional object of the invention to provide a method for implementing IP telephony with QoS using end-to-end RSVP signaling that is efficient in its use of network resources and easy to implement.
To achieve these objects, there is provided a method for implementing IP telephony with QoS using end-to-end RSVP signaling that comprises the transfer of a unique sequence of messages prior to, during, and after IP communications. The sequence is not arbitrary as the parameters communicated in a previous message may be used in the follow-up messages. While the message exchanges for the protocols listed above are well documented and understood when each is used in isolation, this is not the case when they are used together.
The present invention discloses a method whereby the separate protocols are used together to setup, maintain, and teardown Internet communications having an acceptable level of QoS. This is accomplished by dynamically establishing RSVP policy based on SIP telephony requests. The application defines two options for QoS support for IP telephony: PSTN-style xe2x80x9cQoS assuredxe2x80x9d where QoS is guaranteed, and Internet-style xe2x80x9cQoS enabledxe2x80x9d where only partial or no QoS may be available. In addition, the application deploys QoS in two ways: 1) xe2x80x9cPullxe2x80x9d method, QoS is outsourced to the servers or 2) xe2x80x9cPushxe2x80x9d method, QoS is provided locally to the routers.
The method of providing quality of service (QoS) in an Internet Protocol (IP) telephony session between a calling party and a called party, comprises the steps of providing transporting IP media for the session between said calling party and a first device having IP capability; providing transporting IP media for the session between the called party and a second device having IP capability; establishing an IP connection between said first device and the second device; and reserving network resources for the telephony session.
Although the embodiments of the present invention focus more on the xe2x80x9cpullxe2x80x9d method, the present invention employs both methods.
While the present invention focuses on the use of RSVP for end-to-end signaling of QoS reservations, the concepts can also be extended for use with any end-to-end reservation protocol. In addition, the same concept also applies to dynamically establishing DiffServ policy based on SIP telephony requests wherein the policy is provisioned on a real time basis to the router (PUSH) instead of the router querying for the policy on a real time basis (PULL.)